Open topic with navigation

You are here: Setup Schedule > About > Parameters > Precedence Parameters > Parameters List
GEOVIA MineSched

Precedence Parameters

The following parameters can be used in the Parameters column of the Precedences parameters data grid:

Note: Precedence parameters are applicable to only mining and fill locations. The following documentation refers to mining, mining locations, and mining blocks. However, it is equally applicable to filling, fill locations, and fill blocks.

BLOCKS_IN_SEQUENCE

If you set the BLOCKS_IN_SEQUENCE parameter to yes, you force mining to occur in a fixed sequence in the location. The sequence can be based on a polygon string range, or a solid object range, and the mining and fill direction.

If you set BLOCKS_IN_SEQUENCE to no and you have targets defined, the blocks are mined in the sequence that best meets the targets. If you set BLOCKS_IN_SEQUENCE to no and you do not have targets defined, the blocks are mined in the order that they become available.

If the mining method is benches and you set BLOCKS_IN_SEQUENCE to yes, mining occurs one bench at a time. If the mining method is benches and you set BLOCKS_IN_SEQUENCE to no, mining can occur on a lower bench as soon as the blocks in that bench are exposed. The entire upper bench does not have to be mined before blocks in the lower bench can be mined.

The default value for BLOCKS_IN_SEQUENCE changes depending on the value set for Consolidate blocks in the Locations data grid. If Consolidate blocks is selected for the location, the default value for BLOCKS_IN_SEQUENCE is yes. When blocks are consolidated, all blocks perpendicular to the mining direction are consolidated to create a single mining block. Consolidate blocks is usually selected for short-term scheduling within polygons, strip mining, and underground mining where the stope advances consistently across the width of the stope. In these scenarios, usually the only option is to mine in the specified mining direction.

If Consolidate blocks is cleared for the location, the default value for BLOCKS_IN_SEQUENCE is no. When blocks are not consolidated, you are usually scheduling using targets in medium-term or long-term surface mining. In longer term scheduling, you want the flexibility to allow blocks to be mined to meet targets, so you do not usually want the blocks to be mined in a fixed sequence.

If you have not consolidated your blocks, and you are considering changing BLOCKS_IN_SEQUENCE to yes to force mining in a fixed sequence, first consider whether you could achieve the same result by consolidating your blocks. Consolidating the blocks is likely to give you the same scheduling result as setting BLOCKS_IN_SEQUENCE to yes but with a faster processing speed, because the number of mining blocks being scheduled is reduced. The result of consolidating your blocks could, in fact, be more accurate than using BLOCKS_IN_SEQUENCE because the grade would reflect the entire width of the location advancing at a consistent rate.

BLOCK_PRECEDENCES_CONSTRAINED_BY_GROUP

You use the BLOCK_PRECEDENCES_CONSTRAINED_BY_GROUP parameter when you want block precedences to be created only if the blocks both have the same group identifier. That is, you use BLOCK_PRECEDENCES_CONSTRAINED_BY_GROUP only if both blocks have the same string number or solid object number.

BLOCK_PRECEDENCES_CONSTRAINED_BY_GROUP can be used when a spatial relationship exists between two locations and both locations are being mined by polygons, bench polygons, or solids.

You can also use BLOCK_PRECEDENCES_CONSTRAINED_BY_GROUP when BLOCKS_IN_SEQUENCE is set to no, and you want to calculate block precedences within a location based on only the blocks within the same polygon or solid. That is, block precedence calculations are not performed between blocks within different polygons or solids of the same location.

The default value for BLOCK_PRECEDENCES_CONSTRAINED_BY_GROUP is no.

GROUPS_IN_DEFINED_SEQUENCE

You use the GROUPS_IN_DEFINED_SEQUENCE parameter, set to yes, to force mining to occur in a fixed sequence in the location. The sequence is then based on a polygon string range, or a solid object range, and the mining direction within each polygon.

Note: GROUPS_IN_DEFINED_SEQUENCE is valid only if the mining method for the locations is polygons, bench polygons, or solids and BLOCKS_IN_SEQUENCE is set to no. If BLOCKS_IN_SEQUENCE is set to yes, by default the groups are also mined in sequence as though GROUPS_IN_DEFINED_SEQUENCE is set to yes.

It can be useful to choose to mine groups in a defined sequence when you have not consolidated the blocks in the locations, and you want to mine the blocks in a particular sequence based on the string or object range defined for the locations.

If you set GROUPS_IN_DEFINED_SEQUENCE to no, the blocks are mined in the sequence that best meets the targets.

It can be useful to choose not to mine groups in a defined sequence when you want to create a short-term schedule based on targets. In this case, you can set GROUPS_IN_DEFINED_SEQUENCE to no, and define the MAX_ACTIVE_GROUPS in the Parameters data grid. This means that the groups in the location are mined in the order that best meets the targets.

HORIZONTAL_LAG_ALL_DIRECTIONS

You use the HORIZONTAL_LAG_ALL_DIRECTIONS parameter to control the shape of the mining face as it advances on a bench.

You set a value for the parameter that determines when blocks, that are on the same bench as the block currently being mined, become available for mining. To advance a bench face perpendicular to the mining direction, you can set very high values for the horizontal lag.

HORIZONTAL_LAG_ALL_DIRECTIONS controls the availability of blocks based on other blocks on the same horizontal plane. You can define different values for the horizontal lag in each direction using the HORIZONTAL_LAG_NORTH, HORIZONTAL_LAG_EAST, HORIZONTAL_LAG_SOUTH, and HORIZONTAL_LAG_WEST parameters. It is unusual to choose to define different values for the horizontal lag in different directions, so these parameters do not appear on the parameter list. However, they are applied if you type them into the Parameter column.

The default value for horizontal lag in any direction is the block size in that direction. At the default setting, three adjacent blocks must be mined in the rock face before the block behind the central block in the group of three becomes available for mining. The value for horizontal lag should be an integer multiple of the block size in the lag direction. A lag of zero means that the block behind the block currently being mined becomes available for mining when the current block is completed, even if the blocks on either side are not mined.

When the mining direction is a numeric azimuth, the horizontal lag distances are applied relative to the azimuth where north represents the mining direction. This means that the value for West is applied in a direction 90 degrees to the left of the direction of mining, the value for East is applied in a direction 90 degrees to the right of the direction of mining. Only the East and West directions are relevant when the mining direction is an azimuth, and these are usually the same value defined using the HORIZONTAL_LAG_ALL_DIRECTIONS parameter.

In the example below, a HORIZONTAL_LAG_ALL_DIRECTIONS has been set to a value of one block width. To mine the red block, all of the magenta blocks must be mined.

MAXIMUM_LAG_DISTANCE

You use the MAXIMUM_LAG_DISTANCE parameter to define the maximum distance allowed, in the mining direction:

  • between faces on two adjacent benches
  • between faces on two locations for which you have defined a spatial relationship, and which have the same mining direction

Note: MAXIMUM_LAG_DISTANCE is valid for only mining locations.

The VERTICAL_LAG_DISTANCE is the minimum lag distance between adjacent benches or spatially related locations. Therefore the MAXIMUM_LAG_DISTANCE must be greater than the VERTICAL_LAG_DISTANCE in any direction. MineSched ignores the MAXIMUM_LAG_DISTANCE if it is equal to or less than the VERTICAL_LAG_DISTANCE in any direction, and displays a warning to let you know the value will not be used during scheduling.

Tip: Usually, the MAXIMUM_LAG_DISTANCE should be at least the value of the VERTICAL_LAG_DISTANCE plus twice the block size in the mining location. If the VERTICAL_LAG_DISTANCE has not been set, the MAXIMUM_LAG_DISTANCE should be set to at least three times the block size in the mining direction. Using these guidelines for the MAXIMUM_LAG_DISTANCE stops resources having unnecessary downtime while waiting for other resources to complete a block.

VERTICAL_LAG

VERTICAL_LAG_ALL_DIRECTIONS controls the availability of blocks based on:

  • when blocks on the bench above are mined for mining locations
  • when blocks on the bench below are filled for fill locations

VERTICAL_LAG_ALL_DIRECTIONS defines the minimum distance between faces on adjacent benches. The distance between the faces is often referred to as the bench lag, the distance that one bench lags behind another. You can define different values for the vertical lag in each direction using the VERTICAL_LAG_NORTH, VERTICAL_LAG_EAST, VERTICAL_LAG_SOUTH, and VERTICAL_LAG_WEST parameters.

The default value for vertical lag in any direction is the block size in that direction. At the default setting, nine adjacent blocks, in a three-by-three pattern, must be mined in the bench above before the block in the bench below, at the centre of the three-by-three pattern, becomes available. The value for vertical lag should be an integer multiple of the block size in the lag direction. A lag of zero means that the block underneath the current block becomes available as soon as the current block is completed. A lag of zero models sinking a vertical shaft in the pit, which is usually not practical.

When the mining direction is a numeric azimuth, the vertical lag distances are applied relative to the azimuth where north represents the mining direction. This means that the value for West is applied in a direction 90 degrees to the left of the direction of mining, the value for East is applied in a direction 90 degrees to the right of the direction of mining.

Tip: If you have a scenario where the direction of some of the polygons that define the mining direction are numeric and some are text directions, it is good practice to set the text directions to numeric azimuths so that the lags are treated in the same way for all blocks.

Note: After the requirements for vertical lag distance in each direction have been mined in the bench above a block, mining direction constraints on the bench the block is on can still mean that it is not available for mining.

You can set different lag distances between blocks in different locations when spatial relationships are defined between the locations. Defining a location-specific vertical lag means you can define a value for the lag between the blocks in one location to another that is different to the lag that is defined between blocks being mined within the location. To set a vertical lag that is specific to blocks in locations linked by a spatial relationship, type the vertical lag parameter and the name of the location separated by a space. For example, VERTICAL_LAG_ALL_DIRECTIONS PIT specifies the vertical lag from blocks in the PIT location to blocks in the location specified in the Location field, of the row which contains this parameter, in the Precedence parameters data grid.

Setting different lag distances between blocks in different locations is useful if you are backfilling a pit. You can use location-specific vertical lag to define a vertical lag between the mining face and the backfill face that is different to the lag between the mining faces.

Setting a vertical lag between spatially related locations is useful if you are backfilling in your pit and you want to backfill automatically when enough space is created by mining.

The following diagram shows that if a vertical lag distance of 100 is set, the red block cannot be mined until a distance of at least 100 units has been mined from the block to the face of the bench one level above, and between the faces of each successive bench above.

See also

Open topic with navigation